ปลดล็อกประสิทธิภาพของเว็บ: เจาะลึกกลไกแคชการคำนวณขนาดโดยธรรมชาติของ CSS

ในระบบเศรษฐกิจดิจิทัลระดับโลก ประสิทธิภาพของเว็บไม่ใช่เรื่องหรูหรา แต่เป็นข้อกำหนดพื้นฐาน ผู้ใช้จากทุกมุมโลกคาดหวังประสบการณ์เว็บที่รวดเร็ว ราบรื่น และเสถียร หน้าเว็บที่โหลดช้าหรือการเปลี่ยนแปลง Layout ที่ไม่ราบรื่น อาจเป็นความแตกต่างระหว่างลูกค้าใหม่กับโอกาสที่สูญเสียไป ในขณะที่นักพัฒนาซอฟต์แวร์มักจะมุ่งเน้นไปที่การเพิ่มประสิทธิภาพเครือข่ายและการดำเนินการ JavaScript แต่การเพิ่มประสิทธิภาพที่มีประสิทธิภาพซึ่งมักถูกมองข้ามเกิดขึ้นลึกลงไปในเอ็นจินการแสดงผลของเบราว์เซอร์: Intrinsic Size Calculation Cache

กลไกภายในนี้เป็นฮีโร่เงียบๆ ในการแสวงหาประสิทธิภาพ โดยมีบทบาทสำคัญในวิธีที่เบราว์เซอร์สามารถแสดงหน้าเว็บได้อย่างรวดเร็วและมีประสิทธิภาพ การทำความเข้าใจวิธีการทำงานช่วยให้นักพัฒนา Front-End สามารถเขียน CSS และ HTML ที่สอดคล้องกับกลยุทธ์การเพิ่มประสิทธิภาพของเบราว์เซอร์ ซึ่งนำไปสู่การปรับปรุงที่สำคัญในเมตริกหลัก เช่น Core Web Vitals (CWV) บทความนี้จะพาคุณเจาะลึกกลไกการแคชนี้ อธิบายว่ามันคืออะไร ทำไมมันถึงสำคัญ และคุณจะเขียนโค้ดที่ใช้ประโยชน์จากศักยภาพสูงสุดได้อย่างไร

ข้อมูลเบื้องต้นเกี่ยวกับ Browser Rendering Pipeline

ก่อนที่เราจะชื่นชมแคชได้ เราต้องมีความเข้าใจพื้นฐานเกี่ยวกับวิธีที่เบราว์เซอร์เปลี่ยนโค้ดเป็นพิกเซล กระบวนการนี้มักเรียกว่า Critical Rendering Path ซึ่งเกี่ยวข้องกับขั้นตอนสำคัญหลายขั้นตอน ในขณะที่คำศัพท์ที่แน่นอนอาจแตกต่างกันไปในแต่ละเอ็นจินเบราว์เซอร์ (เช่น Blink, Gecko และ WebKit) แต่โฟลว์ทั่วไปจะคล้ายกัน:

• DOM (Document Object Model) Construction: เบราว์เซอร์แยกวิเคราะห์ HTML เป็นโครงสร้างแบบต้นไม้ของโหนดที่แสดงถึงเอกสาร
• CSSOM (CSS Object Model) Construction: เบราว์เซอร์แยกวิเคราะห์ CSS รวมถึงสไตล์ชีตภายนอกและสไตล์ Inline เป็นต้นไม้ของสไตล์
• Render Tree Formation: DOM และ CSSOM จะถูกรวมเข้าด้วยกันเพื่อสร้าง Render Tree ต้นไม้นี้มีเฉพาะโหนดที่จะแสดงผลด้วยสายตาบนหน้าเว็บเท่านั้น (เช่น องค์ประกอบที่มี `display: none` จะถูกละเว้น)
• Layout (หรือ Reflow): นี่คือขั้นตอนสำคัญสำหรับหัวข้อของเรา เบราว์เซอร์คำนวณขนาดและตำแหน่งที่แน่นอนของทุกโหนดใน Render Tree มันกำหนด Geometry ของแต่ละองค์ประกอบ ไม่ว่าจะเป็นจุดเริ่มต้น ความกว้าง ความสูง นี่เป็นกระบวนการที่ต้องใช้การคำนวณอย่างมาก เนื่องจากขนาดขององค์ประกอบอาจได้รับอิทธิพลจากพาเรนต์ ลูก และ Siblings
• Paint: เบราว์เซอร์เติมพิกเซลสำหรับแต่ละองค์ประกอบตาม Geometry และสไตล์ที่คำนวณไว้ ได้แก่ สี เส้นขอบ เงา ฯลฯ ซึ่งเกี่ยวข้องกับการสร้างรายการ Draw Calls
• Compositing: เบราว์เซอร์วาดเลเยอร์ที่ทาสีต่างๆ ลงบนหน้าจอตามลำดับที่ถูกต้องเพื่อสร้างภาพสุดท้าย

ขั้นตอน Layout เป็นปัญหาคอขวดด้านประสิทธิภาพที่น่าอับอาย การเปลี่ยนแปลง Geometry ขององค์ประกอบเพียงครั้งเดียวสามารถกระตุ้นปฏิกิริยาลูกโซ่ บังคับให้เบราว์เซอร์คำนวณ Layout ใหม่สำหรับส่วนใหญ่ของหน้าเว็บ หรือแม้แต่ทั้งเอกสาร นี่คือจุดที่การทำความเข้าใจขนาดโดยธรรมชาติมีความสำคัญอย่างยิ่ง

ขนาดโดยธรรมชาติคืออะไร? ไขความลับมิติโดยธรรมชาติขององค์ประกอบ

ในโลกของ CSS ขนาดขององค์ประกอบสามารถกำหนดได้สองวิธีหลักๆ คือ Extrinsically หรือ Intrinsically

Extrinsic Sizing

นี่คือเมื่อคุณซึ่งเป็นนักพัฒนาซอฟต์แวร์กำหนดขนาดขององค์ประกอบอย่างชัดเจนโดยใช้ CSS ขนาดถูกกำหนดจากภายนอกโดยบริบทหรือสไตล์โดยตรง

ตัวอย่าง:

• div { width: 500px; height: 250px; } - ขนาดคงที่
• div { width: 100%; } - ขนาดถูกกำหนดโดยความกว้างของคอนเทนเนอร์พาเรนต์
• div { width: 50vw; } - ขนาดถูกกำหนดโดยความกว้างของ Viewport

Intrinsic Sizing

นี่คือขนาดโดยธรรมชาติขององค์ประกอบตามเนื้อหา เป็นขนาดที่องค์ประกอบจะใช้หากไม่มีข้อจำกัดภายนอก ขนาดมาจากภายใน

ตัวอย่าง:

• ขนาดโดยธรรมชาติขององค์ประกอบ <img> คือความกว้างและความสูงที่แท้จริงของไฟล์ภาพ (เช่น รูปถ่ายขนาด 1200x800 พิกเซล)
• ขนาดโดยธรรมชาติขององค์ประกอบ <span>Hello World</span> ถูกกำหนดโดยเนื้อหาข้อความ `font-size`, `font-family`, `letter-spacing` และคุณสมบัติทาง Typography อื่นๆ
• ขนาดโดยธรรมชาติขององค์ประกอบ <video> คือมิติของ Video Track
• ขนาดโดยธรรมชาติของปุ่มขึ้นอยู่กับ Label ข้อความ Padding และ Border

การคำนวณขนาดโดยธรรมชาติอาจมีค่าใช้จ่ายสูงอย่างน่าประหลาดใจ สำหรับภาพ เบราว์เซอร์อาจต้องถอดรหัสส่วนหนึ่งของไฟล์เพื่ออ่าน Metadata สำหรับข้อความเกี่ยวข้องกับการคำนวณที่ซับซ้อนที่เกี่ยวข้องกับ Font Metrics และ Character Shaping เมื่อเบราว์เซอร์ดำเนินการ Layout Pass มักจะต้องทราบขนาดโดยธรรมชาติขององค์ประกอบเพื่อปรับขนาดพาเรนต์หรือจัดตำแหน่ง Siblings อย่างถูกต้อง การทำเช่นนี้ซ้ำๆ สำหรับทุกองค์ประกอบในการเปลี่ยนแปลง Layout ทุกครั้งจะช้าอย่างไม่น่าเชื่อ

ฮีโร่ในเรื่องราวของเรา: Intrinsic Size Calculation Cache

เพื่อหลีกเลี่ยงปัญหาด้านประสิทธิภาพของการคำนวณใหม่ตลอดเวลา เอ็นจินเบราว์เซอร์จึงใช้การเพิ่มประสิทธิภาพที่ชาญฉลาด: Intrinsic Size Calculation Cache มันเป็นแนวคิดที่เรียบง่ายแต่ทรงพลัง:

1. คำนวณครั้งเดียว: ครั้งแรกที่เบราว์เซอร์ต้องการกำหนดขนาดโดยธรรมชาติขององค์ประกอบ มันจะดำเนินการคำนวณทั้งหมดที่มีค่าใช้จ่ายสูง
2. จัดเก็บผลลัพธ์: จากนั้นเบราว์เซอร์จะจัดเก็บขนาดที่คำนวณนี้ไว้ในแคชภายใน โดยเชื่อมโยงกับองค์ประกอบนั้น
3. นำกลับมาใช้ใหม่บ่อยๆ: ใน Layout Pass ที่ตามมา หากเบราว์เซอร์ต้องการขนาดโดยธรรมชาติขององค์ประกอบเดิมอีกครั้ง จะไม่คำนวณใหม่ มันเพียงแค่ดึงค่าจากแคช ซึ่งเร็วกว่าหลายเท่า

แคชนี้เป็นการเพิ่มประสิทธิภาพที่สำคัญที่ทำให้หน้าเว็บ Dynamic สมัยใหม่เป็นไปได้ อย่างไรก็ตาม เช่นเดียวกับแคชอื่นๆ มันมีอายุการใช้งานและสามารถถูกทำให้เป็น Invalid ได้ เบราว์เซอร์ฉลาดพอที่จะรู้ว่าเมื่อใดที่ค่าที่แคชไว้ไม่ถูกต้องอีกต่อไป

อะไรเป็นตัวกระตุ้นให้แคชเป็น Invalid?

เบราว์เซอร์ต้องทำให้ขนาดโดยธรรมชาติที่แคชไว้สำหรับองค์ประกอบเป็น Invalid เมื่อใดก็ตามที่มีการเปลี่ยนแปลงที่อาจส่งผลต่อมิติโดยธรรมชาติขององค์ประกอบนั้น ตัวกระตุ้นทั่วไป ได้แก่:

• การเปลี่ยนแปลงเนื้อหา: การแก้ไขข้อความภายใน <div> การเปลี่ยนแปลงแอตทริบิวต์ src ของ <img> หรือการเพิ่มลูกให้กับคอนเทนเนอร์จะทำให้แคชเป็น Invalid
• การเปลี่ยนแปลงคุณสมบัติ CSS: การเปลี่ยนแปลงคุณสมบัติ CSS ที่มีอิทธิพลโดยตรงต่อขนาดโดยธรรมชาติจะบังคับให้ต้องคำนวณใหม่ สำหรับองค์ประกอบข้อความ นี่อาจเป็น font-size, font-weight, letter-spacing หรือ white-space
• การเปลี่ยนแปลงแอตทริบิวต์: การเปลี่ยนแปลงแอตทริบิวต์ที่กำหนดเนื้อหา เช่น value ของ Input หรือ cols และ rows ของ <textarea>

เมื่อแคชเป็น Invalid เบราว์เซอร์จะถูกบังคับให้ดำเนินการคำนวณที่มีค่าใช้จ่ายสูงอีกครั้งในระหว่าง Layout Pass ถัดไป การทำให้เป็น Invalid บ่อยๆ สามารถลบล้างประโยชน์ของแคชและนำไปสู่ปัญหาด้านประสิทธิภาพ

ผลกระทบในทางปฏิบัติและการปรับปรุงประสิทธิภาพ

การทำความเข้าใจกลไกการแคชนี้ไม่ใช่แค่แบบฝึกหัดทางวิชาการ มันมีผลกระทบโดยตรงต่อเมตริกประสิทธิภาพที่มีความสำคัญต่อผู้ใช้และ Search Engine มากที่สุด

การลด Layout Thrashing

Layout Thrashing เป็น Anti-Pattern ด้านประสิทธิภาพที่ร้ายแรง มันเกิดขึ้นเมื่อ JavaScript อ่านและเขียนคุณสมบัติที่มีผลต่อ Geometry ขององค์ประกอบซ้ำๆ และพร้อมกัน พิจารณาสถานการณ์นี้:

            // BAD: Causes Layout Thrashing
function resizeElements(elements) {
  for (let i = 0; i < elements.length; i++) {
    // READ: This forces the browser to perform a layout to get the accurate width.
    const currentWidth = elements[i].offsetWidth;

    // WRITE: This invalidates the layout, because the width is changing.
    elements[i].style.width = (currentWidth / 2) + 'px';
  }
}

            

              
                Copy
              
            
          

ใน Loop นี้ เบราว์เซอร์ติดอยู่ในวงจรที่เจ็บปวด: อ่าน (กระตุ้น Layout) -> เขียน (ทำให้ Layout เป็น Invalid) -> อ่าน (กระตุ้น Layout) -> เขียน (ทำให้ Layout เป็น Invalid) Intrinsic Size Cache บางครั้งสามารถช่วยได้โดยการให้คำตอบอย่างรวดเร็วสำหรับส่วนการอ่าน แต่การทำให้เป็น Invalid อย่างต่อเนื่องยังคงบังคับให้ Layout Engine ทำงานที่ไม่จำเป็น

การปรับปรุง Core Web Vitals (CWV)

แนวคิด Intrinsic Size เชื่อมโยงอย่างใกล้ชิดกับ Core Web Vitals ของ Google ซึ่งเป็นชุดของเมตริกที่วัดประสบการณ์ผู้ใช้ในโลกแห่งความเป็นจริง

• Cumulative Layout Shift (CLS): นี่คือการเชื่อมต่อที่ตรงที่สุด CLS วัดความเสถียรทางภาพ คะแนน CLS สูงมักเกิดขึ้นเมื่อเบราว์เซอร์ไม่ทราบขนาดโดยธรรมชาติขององค์ประกอบก่อนที่จะแสดงผล ตัวอย่างคลาสสิกคือภาพที่ไม่มีมิติ เบราว์เซอร์สำรองพื้นที่เป็นศูนย์สำหรับมัน เมื่อไฟล์ภาพดาวน์โหลดเสร็จสิ้นและเบราว์เซอร์ค้นพบขนาดโดยธรรมชาติ มันจะปรากฏขึ้นทันที ทำให้เนื้อหาโดยรอบทั้งหมดเลื่อน การให้ข้อมูลขนาดล่วงหน้า เราช่วยให้เบราว์เซอร์หลีกเลี่ยงการเลื่อนนี้ได้
• Largest Contentful Paint (LCP): นี่วัดประสิทธิภาพการโหลด หากเบราว์เซอร์ใช้เวลามากเกินไปในขั้นตอน Layout เนื่องจากกำลังคำนวณขนาดใหม่ตลอดเวลา การ Paint องค์ประกอบที่ใหญ่ที่สุดบนหน้าจออาจล่าช้า ทำให้คะแนน LCP แย่ลง
• Interaction to Next Paint (INP): นี่วัดการตอบสนอง งาน Layout ที่ยาวนานจะบล็อก Main Thread ของเบราว์เซอร์ หากผู้ใช้พยายามโต้ตอบกับหน้าเว็บ (เช่น คลิกปุ่ม) ในขณะที่เบราว์เซอร์กำลังยุ่งอยู่กับการคำนวณ Layout ที่หนักหน่วง การตอบสนองจะล่าช้า นำไปสู่คะแนน INP ที่ไม่ดี การใช้ประโยชน์จาก Intrinsic Size Cache อย่างมีประสิทธิภาพจะช่วยลด Main-Thread Work และปรับปรุงการตอบสนอง

นักพัฒนาซอฟต์แวร์จะใช้ประโยชน์ (หรือขัดขวาง) แคชได้อย่างไร

ในฐานะนักพัฒนาซอฟต์แวร์ คุณไม่สามารถควบคุม Intrinsic Size Cache ได้โดยตรง อย่างไรก็ตาม คุณสามารถเขียน HTML และ CSS ที่ทำงานร่วมกับการเพิ่มประสิทธิภาพนี้แทนที่จะขัดขวาง มันเกี่ยวกับการให้ข้อมูลแก่เบราว์เซอร์มากที่สุดเท่าที่จะเป็นไปได้ ตั้งแต่เนิ่นๆ และหลีกเลี่ยงรูปแบบที่ทำให้แคชเป็น Invalid โดยไม่จำเป็น

สิ่งที่ "ควรทำ": แนวทางปฏิบัติที่ดีที่สุดสำหรับแคชที่ดี

1. ให้มิติที่ชัดเจนสำหรับสื่อ

นี่คือแนวทางปฏิบัติที่สำคัญที่สุดสำหรับการป้องกัน CLS และช่วย Layout Engine ของเบราว์เซอร์ ให้ระบุแอตทริบิวต์ width และ height บนองค์ประกอบ <img> และ <video> ของคุณเสมอ

            <!-- GOOD -->
<img src="path/to/image.jpg" width="1200" height="800" alt="...">
            

              
                Copy
              
            
          

เบราว์เซอร์สมัยใหม่ฉลาด พวกเขาจะใช้แอตทริบิวต์เหล่านี้เพื่อคำนวณ Intrinsic Aspect Ratio (1200 / 800 = 1.5) ก่อนที่ภาพจะโหลดด้วยซ้ำ เมื่อรวมกับ `height: auto;` ใน CSS ของคุณ สิ่งนี้จะช่วยให้เบราว์เซอร์สำรองพื้นที่แนวตั้งในปริมาณที่ถูกต้อง ซึ่งจะช่วยขจัดการเลื่อน Layout อย่างสมบูรณ์เมื่อภาพปรากฏขึ้น

2. ใช้คุณสมบัติ CSS `aspect-ratio`

คุณสมบัติ `aspect-ratio` เป็นเครื่องมือที่ทันสมัยและทรงพลังสำหรับการบอกอัตราส่วนโดยธรรมชาติขององค์ประกอบให้เบราว์เซอร์ทราบอย่างชัดเจน เหมาะอย่างยิ่งสำหรับการออกแบบ Responsive และใช้งานได้มากกว่าแค่ภาพ

            .responsive-iframe-container {
  width: 100%;
  aspect-ratio: 16 / 9; /* Tells the browser the intrinsic ratio */
}

.responsive-iframe-container iframe {
  width: 100%;
  height: 100%;
}

            

              
                Copy
              
            
          

โค้ดนี้สำรองพื้นที่บล็อก 16:9 สำหรับคอนเทนเนอร์ เพื่อให้มั่นใจว่าเมื่อเนื้อหาของ Iframe โหลด หน้า Layout จะยังคงเสถียร

3. แยก Subtree ด้วยคุณสมบัติ CSS `contain`

คุณสมบัติ `contain` เป็นคำแนะนำด้านประสิทธิภาพสูงสำหรับเบราว์เซอร์ ช่วยให้คุณสามารถประกาศว่าองค์ประกอบและเนื้อหาขององค์ประกอบนั้นเป็นอิสระจากส่วนที่เหลือของ Document Tree ให้มากที่สุด ค่าที่เกี่ยวข้องมากที่สุดสำหรับเราคือ `size`

contain: size; บอกเบราว์เซอร์ว่าขนาดขององค์ประกอบไม่ได้ขึ้นอยู่กับขนาดของลูก ซึ่งช่วยให้เบราว์เซอร์ข้าม Layout ของลูกได้หากต้องการคำนวณขนาดของคอนเทนเนอร์เท่านั้น ตัวอย่างเช่น หากคุณมีวิดเจ็ตแบบ Self-Contained ที่ซับซ้อน คุณสามารถใช้ `contain: size;` (หรือโดยทั่วไปคือ `contain: content;` ซึ่งรวมถึง `layout` และ `paint` containment ด้วย) เพื่อป้องกันไม่ให้เกิดการคำนวณใหม่ที่มีค่าใช้จ่ายสูงใน Document Layout หลัก

            .complex-widget {
  contain: content;
  /* You must provide an explicit size for contain:size to work */
  width: 300px;
  height: 500px;
}

            

              
                Copy
              
            
          

4. Batch DOM Updates ใน JavaScript

เพื่อหลีกเลี่ยง Layout Thrashing ให้จัดกลุ่มการอ่านและการเขียนของคุณ ขั้นแรก ให้อ่านค่าทั้งหมดที่คุณต้องการจาก DOM จากนั้นทำการเขียนทั้งหมด

            // GOOD: Batched reads and writes
function resizeElements(elements) {
  // 1. READ phase
  const newWidths = [];
  for (let i = 0; i < elements.length; i++) {
    newWidths.push(elements[i].offsetWidth / 2);
  }

  // 2. WRITE phase
  for (let i = 0; i < elements.length; i++) {
    elements[i].style.width = newWidths[i] + 'px';
  }
}

            

              
                Copy
              
            
          

รูปแบบนี้ช่วยให้เบราว์เซอร์ทำการคำนวณ Layout หนึ่งครั้งเพื่อให้ได้ความกว้างทั้งหมด จากนั้นจึงประมวลผลการเปลี่ยนแปลงสไตล์ทั้งหมด ซึ่งอาจกระตุ้นให้เกิด Reflow ครั้งสุดท้ายเพียงครั้งเดียวเมื่อสิ้นสุดการดำเนินการ

สิ่งที่ไม่ "ควรทำ": แนวทางปฏิบัติที่ทำให้แคชเป็น Invalid และทำร้ายประสิทธิภาพ

1. การ Animated คุณสมบัติที่ก่อให้เกิด Layout

ข้อผิดพลาดด้านประสิทธิภาพที่พบบ่อยที่สุดอย่างหนึ่งคือการ Animated คุณสมบัติที่มีผลต่อ Geometry ขององค์ประกอบ คุณสมบัติเช่น width, height, margin, padding, top และ left ล้วนกระตุ้นขั้นตอน Layout ของ Rendering Pipeline การ Animated พวกเขาบังคับให้เบราว์เซอร์เรียกใช้การคำนวณ Layout ในทุกเฟรม

ให้ Animated คุณสมบัติที่ Compositor สามารถจัดการได้: `transform` และ `opacity` คุณสมบัติเหล่านี้ไม่กระตุ้น Layout เบราว์เซอร์มักจะสามารถ Offload Animation ไปยัง GPU ได้ ซึ่งส่งผลให้ Animation 60fps ที่ราบรื่นและไม่บล็อก Main Thread

            /* BAD: Animates layout */
.box.animate {
  animation: move-bad 2s infinite;
}
@keyframes move-bad {
  from { left: 0; }
  to { left: 200px; }
}

/* GOOD: Animates on the compositor */
.box.animate {
  animation: move-good 2s infinite;
}
@keyframes move-good {
  from { transform: translateX(0); }
  to { transform: translateX(200px); }
}

            

              
                Copy
              
            
          

2. การเปลี่ยนแปลงเนื้อหาบ่อยๆ และไม่จำเป็น

หากคุณมี Component ที่อัปเดตบ่อยๆ (เช่น ตัวจับเวลาถอยหลัง, Stock Ticker) โปรดคำนึงถึงวิธีที่การอัปเดตเหล่านั้นส่งผลต่อ Layout หากการเปลี่ยนตัวเลขจาก "10" เป็น "9" ทำให้คอนเทนเนอร์ปรับขนาด คุณกำลังทำให้ Intrinsic Size Cache เป็น Invalid ซ้ำๆ และกระตุ้นการคำนวณ Layout ในกรณีที่เป็นไปได้ พยายามตรวจสอบให้แน่ใจว่าขนาดคอนเทนเนอร์ยังคงเสถียรในระหว่างการอัปเดตเหล่านี้ ตัวอย่างเช่น โดยใช้ Font แบบ Monospace หรือตั้งค่าความกว้างขั้นต่ำ

แอบดูภายใต้ Hood: Browser Developer Tools

คุณสามารถเห็นผลกระทบของการเพิ่มประสิทธิภาพเหล่านี้ (และ Anti-Pattern) ได้โดยใช้ Browser Developer Tools ของคุณ

การใช้ Performance Panel

ใน Chrome DevTools Performance Panel คือเพื่อนที่ดีที่สุดของคุณ คุณสามารถบันทึก Performance Profile ในขณะที่ Animation หรือ Script ของคุณกำลังทำงาน

• Layout Thrashing: มองหาแถบสีม่วงยาวๆ ที่ทำซ้ำๆ ที่มีป้ายกำกับว่า "Layout" หากคุณเห็นคำเตือน Forced Reflow (สามเหลี่ยมสีแดงขนาดเล็ก) นั่นเป็นสัญญาณที่ชัดเจนของ Layout Thrashing
• Animation Performance: บันทึก Animation `left` ที่ "ไม่ดี" และ Animation `transform` ที่ "ดี" ใน Profile ของ Animation `left` คุณจะเห็นชุดงาน Layout และ Paint ในทุกเฟรม ใน Profile ของ Animation `transform` Main Thread ส่วนใหญ่จะไม่ได้ใช้งาน โดยงานจะเกิดขึ้นใน Thread "Compositor"

การแสดงภาพ Layout Shift

ในแท็บ DevTools Rendering (คุณอาจต้องเปิดใช้งานจากเมนูสามจุด > More Tools > Rendering) คุณสามารถเลือกช่อง "Layout Shift Regions" ได้ ซึ่งจะไฮไลต์พื้นที่ของหน้าจอเป็นสีน้ำเงินเมื่อใดก็ตามที่เกิด Layout Shift เป็นเครื่องมือที่ล้ำค่าสำหรับการ Debug ปัญหา CLS ซึ่งมักเกิดจากเบราว์เซอร์ไม่ทราบขนาดโดยธรรมชาติขององค์ประกอบล่วงหน้า

อนาคต: การพัฒนา Browser Optimization

ผู้จำหน่ายเบราว์เซอร์กำลังทำงานอย่างต่อเนื่องเพื่อให้การแสดงผลเร็วขึ้นและชาญฉลาดขึ้น โครงการต่างๆ เช่น RenderingNG (Next Generation) ของ Chromium แสดงถึงการปรับสถาปัตยกรรม Rendering Engine ใหม่ทั้งหมดเพื่อให้มีความน่าเชื่อถือ มีประสิทธิภาพ และคาดการณ์ได้มากขึ้น คุณสมบัติต่างๆ เช่น คุณสมบัติ `contain` เป็นส่วนหนึ่งของแนวโน้มที่กว้างขึ้นในการให้เครื่องมือที่ชัดเจนแก่นักพัฒนามากขึ้นเพื่อสื่อสารความตั้งใจไปยัง Browser Engine

ในฐานะนักพัฒนาเว็บ ยิ่งเราเข้าใจกลไกพื้นฐานเหล่านี้มากเท่าไหร่ เราก็ยิ่งพร้อมที่จะสร้างแอปพลิเคชันที่ไม่เพียงแต่ใช้งานได้ แต่ยังมีประสิทธิภาพอย่างแท้จริงในระดับโลก มอบประสบการณ์ที่เหนือกว่าแก่ผู้ใช้ทุกคน โดยไม่คำนึงถึงอุปกรณ์หรือสภาพเครือข่ายของพวกเขา

สรุป

CSS Intrinsic Size Calculation Cache เป็นการเพิ่มประสิทธิภาพเบื้องหลังที่มีประสิทธิภาพซึ่งทำให้เว็บสมัยใหม่เป็นไปได้ ในขณะที่ทำงานโดยอัตโนมัติ แนวทางปฏิบัติในการเขียนโค้ดของเราสามารถช่วยหรือขัดขวางประสิทธิภาพได้

โดยการ Internalizing Key Takeaways เหล่านี้ คุณสามารถเขียนโค้ด Front-End ที่มีประสิทธิภาพและเป็นมืออาชีพมากขึ้น:

• Layout มีค่าใช้จ่ายสูง: ระลึกถึงการดำเนินการที่กระตุ้นการคำนวณ Layout เสมอ
• ให้ข้อมูลขนาดล่วงหน้า: ใช้แอตทริบิวต์ `width`/`height` บนสื่อและคุณสมบัติ `aspect-ratio` เพื่อป้องกัน Layout Shift และช่วยให้เบราว์เซอร์วางแผน Layout ได้อย่างมีประสิทธิภาพ
• Animated อย่างชาญฉลาด: ต้องการ Animated `transform` และ `opacity` มากกว่าคุณสมบัติที่มีผลต่อ Geometry เพื่อหลีกเลี่ยงงาน Layout และ Paint ที่มีค่าใช้จ่ายสูงต่อเฟรม
• แยกความซับซ้อน: ใช้คุณสมบัติ CSS `contain` เพื่อให้คำแนะนำแก่เบราว์เซอร์เกี่ยวกับส่วนใดของ Layout ของคุณที่เป็น Self-Contained ทำให้สามารถเพิ่มประสิทธิภาพเป้าหมายได้มากขึ้น
• ตรวจสอบโค้ดของคุณ: ใช้ Browser Developer Tools เพื่อตามล่า Forced Reflows, Layout Thrashing และ Layout Shift ที่ไม่จำเป็น

โดยการสร้าง Model ทางความคิดเกี่ยวกับวิธีที่เบราว์เซอร์จัดการการปรับขนาดและ Layout คุณจะเปลี่ยนจากการเขียน CSS ที่ใช้งานได้ไปสู่การออกแบบประสบการณ์เว็บที่รวดเร็ว เสถียร และน่าพึงพอใจสำหรับผู้ชมทั่วโลก